As a supplement to traditional automotive occupant restraint systems such as seat belts, various passive restraint systems have been developed in recent years. Such passive restraint systems are designed to improve the safety of motor vehicle occupants in the event of a sufficiently severe vehicle collision. A popular choice for such a passive restraint system involves the use of an inflatable air bag which, upon detection of a sufficiently severe collision, is typically operable to rapidly inflate one or more air bags toward and around a vehicle occupant.
Occupant injury resulting from a vehicle collision is based, to a large extent, upon a velocity change between the vehicle, which is rapidly decelerating as a result of impact with another mass, and the occupant, which may be considered to be a "free body" in that the occupant continues to move in the direction of travel at the pre-impact velocity. This velocity difference is therefore an important collision discrimination parameter, and many prior automotive air bag systems base deployment timing primarily on comparison of the vehicle velocity with a time-dependent velocity threshold or boundary.
The time-dependent nature of such an approach readily lends itself to well known digital programming techniques, and typical time-dependent and velocity based automotive air bag systems have therefore been designed to be microprocessor-controlled. In such systems, a microprocessor typically monitors vehicle acceleration, and begins execution of an air bag deployment algorithm when the vehicle exceeds a predetermined acceleration threshold value. From vehicle acceleration, the microprocessor calculates a vehicle velocity parameter and evaluates this velocity parameter against a microprocessor-generated velocity threshold curve. From this comparison, the microprocessor then determines whether the collision is of sufficient severity to deploy the air bag(s).
A typical microprocessor-generated velocity threshold curve used in such a system is a piece-wise linear function of velocity over the time period of interest. An example of one known velocity threshold curve 10 is shown in FIG. 1. Referring to FIG. 1, curve 10 consists of a four-breakpoint curve characterized by a minimum constant velocity 12, a maximum constant velocity 20 and three linearly varying velocities 14, 16 and 18 therebetween. The minimum constant velocity 12 is characterized by a minimum velocity value V.sub.TH1 and the maximum constant velocity 20 is characterized by a maximum velocity value V.sub.TH4. The three linearly varying velocities 14, 16 and 18 are each defined in terms of a slope, M, and intercept, B, and have minimum velocities of V.sub.TH1, V.sub.TH2 and V.sub.TH3, respectively associated therewith. A key feature of the time-dependent velocity curve 10 is the ability to tailer the curve to have any number of breakpoints with any desired slope therebetween. This provides the programmer with flexibility to optimize system performance for various different vehicles and various different collision sensing orientations.
Referring to FIG. 2, one known microprocessor-executable software algorithm 50 for generating curve 10 is illustrated. Algorithm 50 begins at step 52, and at step 54, the time from enablement of the algorithm (TFE) is compared with the first breakpoint, T.sub.1. If TFE is less than or equal to T.sub.1, then algorithm execution continues at step 56 where the slope variable M is set equal to zero and the intercept value INT is set equal to V.sub.TH1. If, at step 54, TFE is greater than T.sub.1, algorithm execution continues at step 58 where TFE is compared with the second breakpoint, T.sub.2. If TFE is less than or equal to T.sub.2, then algorithm execution continues at step 60 where M is set equal to slope value M.sub.1, and INT is set equal to intercept value B.sub.1. Referring to FIG. 1, M.sub.1 =(V.sub.TH2 -V.sub.TH1)/(T.sub.2 -T.sub.1), and B.sub.1 =V.sub.TH2 -M.sub.1 *T.sub.2.
If, at step 58, TFE is greater than T.sub.2, algorithm execution continues at step 62 where TFE is compared with the third breakpoint, T.sub.3. If TFE is less than or equal to T.sub.3, then algorithm execution continues at step 64 where M is set equal to slope value M.sub.2, and INT is set equal to intercept value B.sub.2. Referring again to FIG. 1, M.sub.2 =(V.sub.TH3 -V.sub.TH2)/(T.sub.3 -T.sub.2), and B.sub.2 =V.sub.TH3 -M.sub.2 *T.sub.3.
If, at step 62, TFE is greater than T.sub.3, algorithm execution continues at step 66 where TFE is compared with the fourth breakpoint, T.sub.4. If TFE is less than or equal to T.sub.4, then algorithm execution continues at step 68 where M is set equal to slope value M.sub.3, and INT is set equal to intercept value B.sub.3. Referring once more to FIG. 1, M.sub.3 =(V.sub.TH4 -V.sub.TH3)/(T.sub.4 -T.sub.3), and B.sub.3 =V.sub.TH4 -M.sub.3 *T.sub.4. If, at step 62, TFE is greater than T.sub.4, M is set equal to zero and INT is set equal to V.sub.TH4 at step 70.
From steps 56, 60, 64, 66, 68 and 70, algorithm execution continues at step 72 where the microprocessor computes the curve 10 in accordance with the equation Velocity=M*TFE+INT. From step 72, algorithm execution continues at step 74 where program control is returned to its calling routine.
While the foregoing time-dependent velocity threshold generating technique may be easily implemented in software, and is typically done so with a low-cost, general purpose microprocessor, this approach suffers from several inherent drawbacks. For example, low-cost general purpose microprocessors process data at a relatively slow rate, thereby limiting the number of breakpoints and slopes which may be used to construct velocity curve 10. Moreover, implementing a velocity threshold generating algorithm in software limits the rate at which an accelerometer signal can be sampled. This limitation leads to the possibility of missing important vehicle acceleration information which may be occurring at too rapid a rate for the digital system to decipher (i.e. "aliasing" problems). This leads to an unwanted phenomena known as sample point variation, wherein the sensing performance of the system varies depending upon the specific point in the collision where the sample is taken. Unfortunately, increasing the data sampling rate and/or processing speed results a drastic increase in microprocessor cost and system complexity.
As another example of an inherent drawback associated with the microprocessor implementation of a velocity threshold generating algorithm, even low-cost microprocessors consume a relatively large amount of real estate both in silicon area at the integrated circuit level and in circuit board area at the system level. The monetary as well as the space consumption costs may therefore be quite high when compared with an application specific integrated circuit which, by its nature, would be optimized for the specific task to be performed.
What is therefore needed is a circuit for generating time-dependent velocity threshold curves which does not rely on a microprocessor-based algorithm to generate the curves. Such a circuit would eliminate or minimize the aforementioned drawbacks of microprocessor-based air bag systems and would further permit the remainder of the collision sensing algorithm to be implemented in hardware, preferably with an application specific integrated circuit. Such a circuit should ideally be flexible enough to permit construction of a velocity threshold curve using any number of breakpoints and slopes, and should further be low cost in both material and manufacturing costs.